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FOREWORD 


Ultrasystems  Technology  Incorporated,  Sierra  Vista,  Arizona 
assisted  in  the  preparation  of  this  document  under 
Contract  Number  DAEA18-83-C-0003 


PREVIOUS  PAGE  M 
IS  ElANK  __y 

1.  SUMMARY 

1.1  Background 

The  Test  Item  Stimulator  (TIS)  was  developed  by  the  U.S.  Army  Electronic 
Proving  Ground  (USAEPG)  for  the  developmental  and  interoperability  testing  of 
automated  command,  control,  communication,  and  intelligence  (C3I)  systems.  By 
definition,  interoperability  testing  requires  the  testing  of  multiple  systems 
that  communicate  through  the  exchange  of  digital  messages,  verifying  that 
these  systems  meet  their  performance  requirements.  Since  test  scenarios  may 
contain  thousands  of  messages,  an  efficient,  automated  method  is  required  to 
enhance  those  test  message  composition  and  manipulation  capabilities  in  the 
TIS. 


1.2  Objective 


fcThe  Automated  Aids  to  Test  Data  Generation  investigation  was  initiated  to 
provide  a  method  for  automating  the  composition  and  validation  of  scenarios 
used  in  the  developmental  testing  of  message-driven  systems. 


1.3  Summary  of  Procedures 


^-Existing  scenario  development  software  and  procedures  were  examined  to 
identify  processes  amenable  to  automation.  From  those  identified,  specific 
processes  were  selected  for  further  study.  Functional  requirements  were  then 
developed  and  an  Automated  Message  Generation  (AMG)  tool  was  designed. 
Subsequent  project  effort  focused  on  the  implementation  of  this  tool.  ^ 

1.4  Summary  of  Results 


a.  Five  general  categories  of  scenario  development  processes  were 
identified  as  being  amenable  to  automation:  message  format  definition, 
message  generation,  scenario  modification,  scenario  validation,  and  the 
conversion  of  non-TIS  scenarios.  Of  these  processes,  message  generation, 
scenario  modification,  and  non-TIS  scenario  conversion  were  selected  for 
automation. 


b.  A  common  set  of  functional  requirements  for  the  selected  processes 
were  developed:  sets  of  messages  need  to  be  retrieved,  modified,  and  then 
copied  or  replaced;  processing  parameters  and  message  data  should  be  optionally 
input  from  an  external  file  (e.g.,  non-TIS  scenario);  and  there  should  be  some 
mechanism  for  reviewing  and  correcting  the  results  of  this  automated  process¬ 
ing,  prior  to  committing  any  changes  to  the  test  message  data  base. 

c.  The  AMG  tool  was  designed  to  meet  these  requirements.  This  tool 
produces  files  of  data  base  transactions,  which  may  then  be  reviewed, 
modified,  and  committed  to  the  data  base  (resulting  In  the  generation, 
modification,  or  deletion  of  test  messages).  As  an  option,  parameters  ar.d 
message  data  for  the  transaction  generation  phase  of  processing  may  be 
supplied  by  an  exterral  file. 

d.  The  effort  to  implement  the  AMG  tool  resulted  In  the  development  of 
the  transaction  file  generation,  transaction  file  review,  and  transaction  file 
commit  functions,  as  well  as  the  operator  interface  screens. 
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An  analysis  of  existing  scenario  development  procedures  indicated  that 
additional  generation,  modification,  and  conversion  processes  were  amenable  to 
automation.  The  identified  generation,  modification,  and  conversion  require¬ 
ments  were  met  through  the  design  of  a  single  tool  for  processing  test  mes¬ 
sages.  The  validation  of  this  tool  would  require  that  it  be  used  during  the 
testing  of  a  tactical  system. 

1.6  Conclusions 

"~^The  application  of  the  AMG  tool  to  (jis)  scenario  development  processes 
would  serve  to  validate  the  AMG  design.  In  addition,  the  application  of  this 
tool  to  the  development  of  tactically  significant  scenarios  would  result  in 
the  refinement  of  the  AMG  design  and  the  identification  of  additional  proce¬ 
sses  amenable  to  automation. 


1.7  Recommendations 


The  AMG  effort  should  be  continued,  to  demonstrate  an  increased 
capability  to  generate  large,  coordinated  test  message  scenarios.  The  results 
of  applying  this  tool  to  the  system-level  testing  of  message-driven  systems 
may  indicate  that  this  tool  should  be  further  refined  and  integrated  into  the 
TIS. 


2 .  DETA ILS  OF  INVESTIGATION 


The  following  sections  detail  the  investigation  of  scenario  development 
processes  amenable  to  automation,  the  development  of  requirements  for 
functions  to  be  automated,  the  design  of  the  AM6  tool,  and  its  implementation. 
An  overview  of  the  TIS  and  its  test  message  data  base  is  provided  as  appendix 
C. 


2.1  Identification  of  Processes  Amenable  to  Automation 


The  scenario  development  software  of  the  TIS  was  examined,  and  scenario 
developers  using  the  TIS  were  interviewed  in  an  effort  to  identify  test 
message  generation  processes  that  could  be  automated.  The  following  labor- 
intensive  areas  were  identified: 

a.  Message  format  definition.  Before  a  message  can  be  used  as  an 
event  component,  its  field  structure  must  be  defined.  Since  developmental 
testing  may  involve  testing  with  several  types  of  message  formats,  a  large 
amount  of  effort  may  be  involved,  using  current  procedures.  It  would, 
therefore,  be  highly  desirable  to  add  the  capability  of  accepting  machine- 
readable  format  definitions  from  various  sources.  Adding  this  capability  was 
not,  however,  further  investigated,  due  to  the  complexity  of  the  format 
definition  process  and  the  expected  variety  in  the  format  definition  inputs. 

b.  Message  generation.  Since  test  scenarios  contain  a  large  number 
of  messages  and  their  transmission  times  and  content  typically  have  well 
defined  relationships  with  mathematical  models,  a  variety  of  test  message 
generation  processes  are  potentially  amenable  to  eatomation. 

c.  Scenario  modification.  Once  a  scenario  has  been  developed, 
testing  requirements  may  change;  thus,  the  capability  of  changing  transmission 
times  and  data  fields  in  mass  would  be  desirable. 

d.  Scenario  validation.  A  need  for  static  scenario  validation 
tools  was  identified;  however,  a  further  examination  of  TIS  software  revealed 
a  number  of  useful  data  reduction  and  analysis  tools  already  existing  in 
post-test,  that  were  capable  of  processing  scenario  files  directly. 

e.  Conversion  of  non-TIS  scenarios.  Automating  the  input  of  test 
messages  into  the  TIS  data  base  from  non-TIS  scenario  files  would  reduce  the 
data  entry  efforts  currently  required  to  manually  generate  these  scenarios. 

2.2  Automated  Test  Message  Processing  Requirements 

The  message  generation,  scenario  modification,  and  non-TIS  scenario 
loading  processes  were  further  investigated.  A  common  set  of  automated 
processing  requirements  were  identified. 

2.2.1  Message  Retrieval 

When  generating  new  messages,  it  is  desirable  to  use  an  existing  message 
as  a  template,  modifying  only  those  fields  that  differ  from 
message- to-message.  Also,  a  retrieval  of  target  messages  insures  that 
messages  to  be  replaced  or  deleted  are  in  the  data  base.  Thus,  the  retrieval 
of  messages  is  common  to  the  processes  to  be  automated.  The  following 
retrieval  requirements  were  identified: 


•  Any  existing  message  should  be  available  for  use  as  a  template. 


•  Message  retrieval  should  be  based  on  the  values  of  key  fields, 
control  fields,  or  data  fields. 

•  Message  retrieval,  based  on  occurrence  in  a  specific  scenario, 

I  should  be  allowed. 

•  Single  message  or  multiple  message  retrieval  should  be  allowed. 

•  The  processing  order  of  a  multiple  message  retrieval  should  be 

'  selectable. 

I 

t 

\  •  The  retrieval  of  messages  of  different  types  and  from  more  than 

one  event  should  be  allowed. 

2.2.2  Message  Processing 

Automating  message  processing  requirements  were  found  to  be  complex  and 
application-specific.  However,  a  number  of  features  were  identified  that, 
when  combined,  would  allow  for  the  automation  of  a  wide  variety  of  complex 
applications: 

•  In  addition  to  specifying  field  values  through  constant  parame¬ 
ters,  these  values  should  be  generated  using  algorithmic  processes.  The 
capability  of  specifying  a  sequence  of  mathematical  or  string  functions, 
operating  on  control  and  data  fields,  was  found  to  be  desirable. 

•  The  generation  of  field  values  should  be  based  on  the  values  of 
constants,  one  or  more  fields  of  the  current  message  or  the  previous  message, 
random  values,  or  temporary  variables. 

t  Certain  control  fields  should  not  be  modified.  In  addition,  a 
mechanism  must  be  provided  for  the  validation  of  fields  that  are  modified. 

•  Although  the  modification  of  messages  in  events  used  to  define  one 
scenario  could  lead  to  the  inadvertent  modification  of  other  scenarios,  the 
modification  these  messages  should  be  allowed,  if  explicitly  requested. 

•  A  conditional  processing  mechanism  would  be  required  for  data 
generation  applications  that  are  not  readily  specified  using  an  algorithmic  or 
functional  approach. 

2.2.3  Utilization  of  External  Files 

In  some  cases,  this  message  selection  and  processing  would  be  most 
conviently  specified  by  a  single  set  of  parameters;  while  In  other  cases, 
message  selection  and  processing  would  be  more  appropriately  specified  by  a 
file  of  records  containing  these  parameters.  The  use  of  external  files  to 
supply  control  and  data  information  would  provide  the  basic  mechanism  for 
loading  non-TIS  scenarios.  To  utilize  a  wide  variety  of  inputs  and  to  provide 
flexibility,  there  should  be  a  mechanism  for  defining  the  field  structure  of  a 
particular  file  and  for  specifying  any  processing  needed  prior  to  using  data 
from  these  fields. 
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2.2.4  Review  and  Modification  of  Results 


The  results  of  any  automated  processing  should  be  available  for  review 
and  correction  prior  to  committing  them  to  the  test  message  data  base.  The 
message  data  should  be  presented  in  a  character  format,  and  only  those  fields 
that  are  affected  by  processing  should  be  displayed.  A  processing  mechanism, 
similar  to  that  described  for  modifying  retrieved  messages,  should  be  provided 
to  allow  corrections  prior  to  committing  changes  to  the  data  base. 

2.3  Automated  Message  Generation  Function 

Based  on  the  automation  requirements  identified,  an  AM6  tool  was  designed 
to  be  run  as  a  stand-alone  system  or  as  a  sub-function  of  the  TIS  pre-test. 

2.3.1  Overview 


The  AMG  function  generates  files  of  data  base  transactions,  called 
tranfiles,  and  uses  these  files  to  create,  modify,  and  delete  data  base  mes¬ 
sages.  The  AMG  function  also  generates  tranfile  listings  and  allows  the 
modification  and  reuse  of  these  files.  An  external  file,  called  a  driver 
file,  can  be  used  to  control  tranfile  generation.  Figure  1  depicts  the  data 
flow  of  the  AMG  function. 

2. 3. 1.1  Transaction  File  Generation 

Tranfiles  are  generated  using  operator-defined  tools  called  generators. 
Generators  retrieve  messages  from  the  data  base,  process  the  control  and  data 
fields  of  these  messages,  and  generate  tranfile  records  that  are  later  used  to 
append,  replace,  or  delete  messages.  Generator  processing  parameters  may  be 
initialized  by  the  operator  or  may  be  specified  by  a  driver  file.  Generator 
definitions  are  stored  in  the  data  base  and  may  be  reused. 

2.3. 1.2  Transaction  File  Review  and  Modification  Prior  to  Commit 

Tranfiles  may  be  reviewed  and  modified,  prior  to  committing  their  trans¬ 
actions  to  the  data  base.  Tranfile  records  may  be  examined,  modified,  and 
written  into  a  second  tranfile,  using  operator-defined  tools  called  modifiers. 
Like  generators,  modifiers  are  stored  in  the  data  base  and  may  be  reused. 
Tranfile  listings  are  available  for  manual  review. 

2.3. 1.3  Specification  of  Processing  Options 

At  certain  points  during  generator  and  modifier  processing,  operator- 
defined  sequences  of  instructions  are  processed.  These  instructions,  called 
actions,  allow  application-specific  message  processing  by  affecting  internal 
generator  and  modifier  variables. 

2.3. 1.3.1  Action  Blocks 

Action  blocks  are  lists  of  operator-specified  actions  to  be  Invoked  at 
specific  points  during  modifier  and  generator  processing.  Generators  have 
three  action  blocks: 
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•  Initialization  actions.  These  actions  are  invoked  one  time,  at 
the  beginning  of  tranfile  generation. 

•  Record  actions.  These  actions  are  invoked  each  time  a  driver  file 
record  is  input. 

•  Message  actions.  These  actions  are  invoked  each  time  a  message 
(segment)  is  retrieved. 

Modifiers  have  two  action  blocks: 

•  Initialization  actions.  These  actions  are  invoked  at  the  begin¬ 
ning  of  tranfile  modification. 

•  Tranfile  record  actions.  These  actions  are  invoked  each  time  a 
tranfile  record  is  input. 

2.3. 1.3.2  Actions  and  Variables 

a.  Actions  are  used  to  modify  internal  variables  and  control  generator 
or  modifier  processing.  They  are  specified  by  adding  an  action  line  to  the 
appropriate  action  block.  Action  lines  consist  of  an  action  keyword  and  a 
list  of  qualifying  parameters  which  identify  the  specific  variables  affected 
or  other  processing  options. 

b.  Actions  fall  into  the  following  general  categories: 

a  Data  movement.  These  actions  are  used  to  move  data  between 
message  fields  and  other  internal  variables. 

•  String  and  mathematical  functions.  These  actions  are  used  to 
generate  and  manipulate  data. 

•  Control.  These  actions  are  used  to  provide  conditional  processing 
and  interrupt  or  change  normal  processing. 

•  Transaction  generation.  These  actions  are  used  to  generate 
transaction  records. 

c.  Internal  variables  can  be  accessed  and  modified  by  referencing  them 
in  action  parameter  lists.  These  following  types  of  information  are 
accessible  as  variables: 

a  Event  Composition  record  fields.  Message  key  fields  and  control 
fields  are  stored  in  variables.  The  Message  Type  and  Message  Index  fields  are 
read-only  type  variables. 

t  Field  Data  record  fields.  These  fields  are  accessible  only 
through  special  data  movement  actions  that  move  them  to  and  from  variables. 

a  Driver  file  record  fields.  Driver  file  record  fields  ara  loaded 
into  variables  according  to  a  specified  format  definition. 


•  Tranfile  record  fields.  During  tranfile  generation,  tranfile 
records  are  generated,  using  data  from  specific  variables.  During  tranfile 
modification,  these  same  variables  are  loaded  from  tranfile  records  of  the 
original  tranfile  and,  after  tranfile  record  action  processing,  they  are  used 
to  generate  tranfile  records  in  the  new  tranfile. 

•  Processing  status.  Generator  and  modifier  status  variables  are 
updated  during  processing. 

•  In  addition,  to  these  variables,  general  purpose  variables  are 
available  for  temporary  storage  of  information:  character  strings  (up  to  100 
characters  long),  integers,  and  floating  point  numbers. 

d.  Specific  details  on  actions  and  variables  are  detailed  in  the  AMG 
Operator  Manual. 

2.3.2  Generators 

Tranfile  generators  retrieve  messages,  modify  message  fields,  and 
generate  data  base  transactions.  Message  retrieval  is  specified  using  a 
retrieval  qualification  expression  which  selects  a  group  of  messages.  In 
addition,  single  and  multiple  message  retrievals  may  be  specified.  A 
generator  may  be  set  up  to  operate  in  a  one-pass  mode  or  in  a  file-driven 
mode,  where  generator  processing  is  invoked  once  per  driver  file  record. 

2.3.2. 1  Generator  Initialization  Actions 

The  first  step  of  generator  processing  is  the  interpretation  of  any 
initialization  actions  specified.  If  any  initialization  actions  errors  occur, 
generator  processing  is  terminated. 

2. 3. 2. 2  Driver  File  Processing 

a.  If  a  generator  is  file-driven,  driver  file  records  are  read,  one  at  a 
time,  and  processed.  Records  are  read  into  a  buffer  and  then  moved  into 
variables,  according  to  a  record  field  definition  called  a  format.  Record 
actions  are  then  interpreted  prior  to  message  retrieval  processing.  If  a 
generator  is  not  file-driven,  message  retrieval  processing  immediately  follows 
initialization  actions. 

b.  The  movement  of  data  from  driver  file  record  fields  into  variables  Is 
controlled  by  operator-defined  formats.  Formats  contain  a  list  of  field 
definitions  that  specify  the  start  column  and  length  of  the  field  to  move  and 
the  destination  variable. 

c.  After  record  fields  are  moved  any  specified  record  actions  are 
invoked.  If  any  errors  occur  during  the  data  movement  or  record  actions 
processing,  an  error  transaction  Is  generated,  message  retrieval  processing  Is 
skipped,  and  processing  continues  with  the  reading  of  the  next  dflvtr  file 
record . 
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2. 3. 2. 3  Message  Retrieval  Processing 

a.  During  message  retrieval  processing,  messages  are  retrieved  from  the 
TIS  test  message  data  base,  with  the  message  selection  specified  by  a 
retrieval  gualification  expression.  Each  of  the  messages  retrieved  is  then 
processed  by  invoking  the  actions  in  the  message  actions  block. 

b.  The  following  options  are  available  for  controlling  the  processing  of 
the  retrieved  messages: 

•  Single  message  retrieval.  This  option  results  in  the  processing 
of  only  one  message. 

•  Multiple  retrieval,  unsorted.  This  option  results  in  the  process¬ 
ing  of  all  messages  meeting  the  retrieval  qualification  requirements  in  the 
order  they  were  retrieved  from  the  data  base  (this  order  is  not  necessarily 
the  order  that  messages  were  added  to  the  data  base).  This  option  speeds  up 
processing,  since  no  sorting  is  required. 

•  Multiple  retrieval,  sorted.  This  option  results  in  the  processing 
of  messages  in  ascending  order  of  System  ID,  Event  ID,  Message  Delta  Time,  and 
Segment  Number.  Thus,  segments  are  grouped  together,  messages  are  grouped 
within  events,  and  events  within  systems. 

2.3. 2.4  Retrieval  Qualification 

a.  Operator-defined  retrieval  qualification  expressions  specify  ranges 
of  values  that  fields  of  data  base  messages  are  compared  against.  These 
expressions  have  the  same  syntax  as  INGRES  where  clauses,  with  an  additional 
feature  allowing  the  substitution  of  internal  variables  for  constants.  Thus, 
driver  file  fields  can  be  read  into  variables  and  used  to  select  messages  to 
be  processed. 

b.  In  the  case  where  no  messages  in  the  data  base  meet  the  retrieval 
qualification  constraints,  an  error  transaction  is  generated,  no  message 
actions  processing  occurs,  and,  if  the  generator  is  file-driven,  processing 
continues  with  the  reading  of  the  next  driver  file  record. 

2.3.2. 5  Message  Processing 

Each  message  retrieved  is  processed  by  invoking  the  operator-defined 
message  actions.  The  key  and  control  fields  of  the  current  message  segment 
are  accessible  as  variables  that  can  be  modified  by  numeric  and  string 
processing  actions.  The  data  fields  (Field  Data  records)  can  be  retrieved  and 
modified,  using  special  data  movement  actions.  Field  values  can  be  checked, 
using  conditional  processing  actions.  After  control  and  data  field  modifica¬ 
tion,  transaction  generating  actions  are  used  to  append,  replace,  or  delete 
the  current  message. 

2. 3. 2. 6  Transaction  Generation 

a.  Two  types  of  data  base  transaction  records  are.; generated  ifeeft  nee  - 
messages  are  appended  to  the  data  base: 


•  Message  copy.  This  type  of  transaction,  when  committed  to  the 
data  base,  results  in  the  creation  of  a  new  Event  Composition  record  and  a  set 
of  Field  Data  records.  The  Event  Composition  fields  are  supplied  by  the 
transaction  record  (modified  template  message),  except  for  the  Message  Index, 
which  is  allocated  during  commit  processing.  The  Field  Data  records  are 
copied  directly  from  the  template  message,  using  the  original  Message  Index. 

•  Field  Replace.  This  type  of  transaction,  when  committed  to  the 
data  base,  results  in  the  replacement  of  the  Data  field  of  a  Field  Data 
record.  One  transaction  record,  of  this  type,  is  generated  for  each  data 
field  that  is  modified,  prior  to  a  Message  Append  (and  Replace).  This  trans¬ 
action  must  be  preceded  by  either  a  Message  Copy  or  a  Message  Replace  trans¬ 
action,  since  those  transactions  set  up  the  current  Message  Index. 

b.  Two  types  of  transaction  records  are  generated  when  existing  messages 
are  modified: 

•  Message  replace.  This  transaction,  when  committed  to  the  data 
base,  results  in  the  modification  of  an  Event  Composition  record.  This  type 
of  transaction  record  contains  two  sets  of  key  fields:  the  original  retrieved 
key  fields  (which  specify  the  record  to  be  modified)  and  the  modified  key 
fields  (which  may  have  been  modified  during  message  processing). 

•  Field  replace.  This  is  the  same  type  of  transaction  used  to 
append  new  messages  (in  both  message  appending  and  message  replacement.  Field 
Replace  transactions  are  applied  to  the  field  of  the  current  message,  whether 
they  have  been  copied  by  a  Message  Copy  or  specified  by  a  Message  Replace). 

c.  Message  delete  transactions  are  generated  In  order  to  delete  a 
message.  This  transaction,  when  committed  to  the  data  base,  results  in  the 

„  deletion  of  the  specified  Event  Composition  record  and  all  Field  Data  records 

j  associated  with  it,  through  its  Message  Index. 

d.  Error  transactions  are  generated  to  signal  special  or  unusual  condi¬ 
tions.  Although  these  transactions  appear  in  listings,  they  do  not  have  any 
effect  on  the  data  base  when  committed. 

2.3.3  Transaction  File  Review,  Modification,  and  Committing 

Tranfile  listings  may  be  generated  for  review,  prior  to  committing 
tranflles.  If  any  changes  are  required,  a  tranfile  can  be  processed  sequen¬ 
tially,  resulting  In  the  generation  of  another  tranfile.  When  tranflles  are 
committed  to  the  data  base,  a  number  of  checks  are  made  to  insure  that  the 
changes  do  not  adversely  affect  other  test  message  data  base  users. 

2. 3. 3.1  Transaction  File  Listing 

Tranfile  listings  display  the  transaction  record  fields: 

•  Transaction  number.  This  field  Is  present  In  all  tranfile 
records.  This  number  indicates  the  order  that  the  records  were  generated, 
which  would  otherwise  be  lost  if  the  tranfile  were  sorted. 
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•  Key  fields.  These  fields  are  the  Event  Composition  key  fields  for 
Message  Copy,  Field  Replace,  and  Message  Delete  transactions.  These  fields 
are  the  new  key  field  values  for  Message  Replace  transactions.  These  fields 
are  not  found  in  error  and  warning  type  transactions. 

•  Message  type.  This  field  is  found  in  all  data  base  type  trans¬ 
actions. 

•  Transaction  type.  This  field  is  found  in  all  tranfile  records. 

•  Field  #.  This  field  is  found  in  data  base  type  transactions.  It 
has  a  value  of  zero,  if  it  is  a  Message  Copy,  Message  Replace,  or  a  Message 
Delete.  It  contains  the  Field  #,  if  it  is  a  Field  Replace  type  transaction. 

§  Override  flag.  This  field  appears  in  data  base  type  transactions, 
except  for  the  Field  Replace.  This  flag  is  used  to  bypass  scenario  modifi¬ 
cation  checking. 

•  Control  fields.  These  fields  appear  in  data  base  transactions, 
except  for  the  Field  Replace.  Message  Replace  transactions  also  include  the 
original  key  fields. 

•  Field  data.  Field  Replace  transactions  have  this  field,  which 
contains  message  field  data. 

•  Text.  Error  transactions  contain  text  fields. 

2.3 .3.2  Transaction  File  Modification 

Modifiers  sort  and  then  sequentially  process  tranfiles,  producing  other 
tranfiles  (the  original  tranfile  is  not  changed).  Like  generator  processing, 
modifier  processing  can  be  controlled  through  operator-specified  actions. 
Modifiers  can  be  used  to: 

•  Detect  and  correct  error  conditions. 


t  Change  delta  times  (allowing  reordering  and  resequencing). 

t  Generate  several  similar  transaction  files  from  an  original. 

2. 3. 3. 2.1  Sorting  and  Filtering 

a.  Prior  to  sequential  processing,  an  optional  sort  is  performed.  The 
following  options  are  available: 

•  Sort  by  transaction  number.  This  option  causes  the  tranfile 
records  to  be  processed  in  the  same  order  they  were  generated. 

t  Sort  by  key.  This  option  groups  fields  within  segments,  segments 
within  messages,  messages  within  events,  and  events  within  systems. 

e  No  sort.  The  tranfile  is  processed  without  first  sorting. 

b.  Specific  types  of  transactions  can  be  selected  for  processing.  The 
following  filtering  options  are  available: 


•  All  transactions.  Data  base  and  error  transactions  are  processed. 


•  Data  base  transactions  only.  Message  Copy,  Message  Replace,  Field 
Replace,  and  Message  Delete  transactions  are  processed. 

•  Error  only.  Error  transactions  are  processed. 

•  No  processing.  This  option  sorts  the  tranfile,  producing  a  new 
tranfile,  without  further  processing. 

2. 3. 3. 2. 2  Transaction  Record  Modification 


a.  Prior  to  sequential  tranfile  record  processing,  operator-specified 
initialization  actions  are  processed.  If  any  errors  occur  during  initial¬ 
ization  action  processing,  modifier  processing  stops. 

b.  Tranfile  records  are  read  and  processed,  one  at  a  time.  The  various 
tranfile  record  fields  are  read  into  variables,  where  they  may  be  accessed 
through  tranfile  record  actions.  The  old  key  fields,  message  index,  and 
message  type  fields  cannot  be  modified.  Unless  otherwise  specified,  each 
tranfile  record  is  written  to  the  new  tranfile,  after  tranfile  record  actions 
processing. 

2. 3. 3. 3  Committing  Data  Base  Transactions 

Tranfiles  are  committed  to  the  TIS  data  base  by  sequentially  applying 
tranfile  records.  Any  error  conditions  result  in  the  generation  of  a  commit 
error  log  tranfile,  containing  error  messages.  When  an  error  occurs  during 
the  processing  of  a  tranfile  record,  an  error  transaction  is  generated  and 
processing  continues  with  the  next  record.  The  following  error  conditions  can 
occur: 


§  Modification  of  scenario  components.  Since  events  are  used  to 
build  scenarios,  the  modification  of  an  event  in  one  scenario  can  result  in 
the  inadvertent  modification  of  other  scenarios.  Message  Copy,  Message 
Replace,  and  Message  Delete  transactions  have  an  Override  Flag,  which 
indicates  whether  or  not  these  transactions  can  be  applied  if  their  Event  ID 
fields  are  found  in  any  Scenario  Composition  records. 

t  Uniqueness.  Message  copy  transaction  key  fields  must  not  match  an 
existing  message.  Otherwise,  this  transaction  could  inadvertently  replace  an 
existing  message. 

•  Missing  message.  The  Message  Replace  and  Message  Delete  trans¬ 
action  key  fields  must  reference  an  existing  message. 

2.4  Automated  Message  Generation  Function  Implementation 

a.  The  effort  to  implement  the  AMG  function  resulted  In  the  development 
of  an  operator  Interface,  a  file-driven  generator  function,  and  tranfile 
listing,  modification,  and  commit  functions. 
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b.  A  high-level,  menu-driven  interface  to  the  AMG  functions  was  devel¬ 
oped.  This  interface  was  designed  to  be  included  as  a  sub-function  to  the 
Event  Definition  Index  function  of  the  TIS  pre-test  (see  figure  2),  or  to  be 
run  as  a  stand-alone  tool. 

c.  The  AMG  Menu  screen  is  used  to  select  one  of  the  three  main  areas  of 
AMG  processing: 

«  Generators.  This  area  includes  the  definition  and  application  of 
tranfile  generators  (control  passed  to  the  Generator  Index  screen). 

•  Tranfiles.  This  area  includes  the  listing,  committing,  and 
deletion  of  tranfiles  (control  passed  to  the  Transaction  File  Index  screen). 

§  Modifiers.  This  area  includes  the  definition  and  application  of 
tranfile  modifiers  (control  passed  to  the  Modifier  Index  screen). 

d.  The  following  sections  detail  the  operator  interface  to  the  AMG 
functions  (see  figure  3).  Additional  details  can  be  found  in  the  AMG  Operator 
Manual . 


2.4.1  Generator  Index 

This  screen  displays  a  list  of  existing  tranfile  generators  and  provides 
access  to  the  following  functions: 

•  Create.  This  function  creates  a  new  generator,  with  default 
processing  options  specified.  Control  is  passed  to  the  Generator 
Specification  screen,  where  this  new  generator  can  then  be  tailored  to  a 
specific  application. 

a  Specify.  This  function  retrieves  an  existing  generator,  allowing 
the  processing  options  of  this  generator  to  be  changed  (Generator  Specifica¬ 
tion). 

•  Delete.  This  function  deletes  an  existing  generator. 

•  Generate.  This  function  generates  a  tranfile,  using  the  specified 
processing  options. 

•  List.  This  function  generates  a  hard-copy  listing  of  a 
generator's  processing  options. 

2.4. 1.1  Generator  Specification 

The  Generator  Specification  screen  is  used  to  view  and  modify  the  pro¬ 
cessing  options  of  a  generator.  The  following  functions  are  accessed  through 
this  screen: 

•  INIT.  This  function  passes  control  to  the  Initialization  Actions 

screen. 
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•  REC.  This  function  passes  control  to  the  Record  Actions  screen. 

•  MSG.  This  function  passes  control  to  the  Message  Actions  screen. 

•  Formats.  This  function  passes  control  to  the  Format  Definition 
screen,  where  driver  file  format  maintenance  functions  are  accessed. 

•  Quit.  This  function  causes  an  exit  from  this  screen,  without 
applying  any  changes  to  the  current  generator  specification. 

2.4. 1.1.1  Generator  Actions  Screens 


a.  Generator  action  blocks  are  maintained  through  the  following  screens: 

•  Initialization  Actions. 

•  Driver  File  Record  Actions. 

•  Message  Actions. 

b.  The  fol  lowing  functions  are  accessed  through  these  screens: 

•  Insert.  This  function  allows  the  addition  of  an  action  line. 

•  Delete.  This  function  deletes  an  action  line. 

•  Quit.  This  function  allows  an  exit  *rom  the  actions  screen, 
without  applying  any  changes  that  were  made  to  the  data  base. 

c.  A  basic  set  of  actions  have  been  implemented  which  can  be  expanded  as 
additional  processing  requirements  are  identified. 

2.4. 1.1.2  Format  Definition 

This  screen  displays  a  list  of  formats  and  provides  access  to  these 
functions: 


•  Create.  This  function  creates  a  new  format  definition  and  passes 
control  to  the  Format  Specification  screen. 

t  Specify.  This  function  retrieves  an  existing  format  definition 
and  passes  control  to  the  Format  Specification  screen. 

•  Delete.  This  function  deletes  a  format  definition. 

2. 4. 1.1. 2.1  Format  Specification 

This  screen  is  used  to  view  and  modify  format  definitions.  The  following 
functions  are  accessed  through  this  screen: 
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•  Insert.  This  function  adds  a  new  field  definition  line. 

•  Delete.  This  function  deletes  a  field  definition  line. 

•  Quit.  This  function  allows  the  exit  from  this  screen,  without 
applying  any  changes. 

2.4.2  Transaction  File  Index 


This  screen  displays  a  list  of  tranfiles  that  have  been  created  or 
modified.  The  following  functions  are  accessible  through  this  screen: 

a  List.  This  function  generates  a  hard-copy  listing  of  a  tranfile. 

t  Delete.  This  function  deletes  a  tranfile. 

•  Commit.  This  function  applies  the  transactions  of  a  tranfile  to 
the  test  message  data  base. 

2.4.3  Modifier  Index 


This  screen  displays  a  list  of  existing  tranfile  modifiers  and  provides 
access  to  the  following  functions: 

•  Create.  This  function  creates  a  new  modifier  with  default  pro¬ 
cessing  options  specified.  Control  is  then  passed  to  the  Modifier  Specifica¬ 
tion  screen. 

•  Specify.  This  function  retrieves  an  existing  modifier  and  passes 
control  to  the  Modifier  Specification  screen. 

t  Delete.  This  function  deletes  an  existing  modifier. 

•  Modify.  This  function  modifies  a  tranfile,  using  the  specified 
processing  options. 

•  List.  This  function  generates  a  hard-copy  listing  of  a  modifier's 
processing  options. 

2.4.3. 1  Modifier  Specification 

The  Modifier  Specification  screen  is  used  to  view  and  modify  the  process¬ 
ing  options  of  a  modifier.  The  following  functions  are  accessed  through  this 
screen: 


•  INIT.  This  function  passes  control  to  the  Initialization  Actions 

screen. 


t  TRAN.  This  function  passes  control  to  the  Tranfile  Record  Actions 

screen. 


•  Quit.  This  function  causes  an  exit  from  this  screen,  without 
applying  any  changes  to  the  current  modifier  specification. 
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2.4.3. 1.1  Modifier  Actions  Screens 

a.  Modifier  action  blocks  are  maintained  through  the  following  screens 

•  Initialization  Actions. 

•  Tranfile  Record  Actions. 

b.  The  following  functions  are  accessed  through  these  screens: 

•  Insert.  This  function  allows  the  addition  of  an  action  line. 

•  Delete.  This  function  deletes  an  action  line. 

•  Quit.  This  function  allows  an  exit  from  the  actions  screen, 
without  applying  any  changes  that  were  made  to  the  data  base. 
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METHODOLOGY  INVESTIGATION  PROPOSAL 


1.  TITLE.  Automated  Aids  to  Test  Data  Generation. 

2.  CATEGORY.  VISTA,  DC3I,  SMI/Interoperabil ity.  Software. 

3.  INSTALLATION.  U.S.  Army  Electronic  Proving  Ground,  Fort  Huachuca,  AZ 
85613. 


4.  PRINCIPAL  INVESTIGATOR.  Richard  Jacques,  Software  and  Automation  Branch, 
STEEP-MT-DA,  AUTOVON  879-1879. 

5.  STATEMENT  OF  THE  PROBLEM.  A  method  is  required  for  a  test  officer  to 
generate  technically  significant  sets  of  coordinated  test  messages  for  use  in 
system-level  testing  of  message-driven  systems. 

6.  BACKGROUND. 

a.  History.  The  Army  and  DOD  have  developed  and  are  continuing  to 
develop  a  number  of  major  automated.  Command,  Control,  Communications,  and 
Intelligence  (C3I)  systems.  These  include  such  systems  as  TACFIRE,  Maneuver 
Control  System,  AN/TYC-39,  AN/TSQ-73,  and  ASAS.  These  systems  are  designed  to 
interface  with  a  large  number  of  interactive  systems  and  to  operate  in  a 
highly  interactive  environment.  The  critical  element  in  the  success  or 
failure  of  these  C3I  systems  will  be  their  interoperability  and  performance 
under  load  in  a  highly  interactive  tactical  environment.  To  date,  no  test 
capability  exists  which  can  fully  evaluate  the  interoperability  of  these 
complex  data  handling  systems. 

b.  A  basic  test  message  composition  and  manipulation  capability  was 
developed  and  demonstrated  as  part  of  the  Interim  Test  Item  Stimulator  (ITIS) 
pre-test  system.  This  process  was  further  automated  during  the  development  of 
the  Test  Item  Stimulator  (TIS).  However,  scenario  generation,  the  process  of 
combining  a  multitude  of  messages  and  the  information  required  to 
automatically  control  their  application,  was  still  found  to  be  a  labor 
intensive  task. 

7.  GOAL.  To  develop  methods  of  automatically  generating  information  that  can 
be  inserted  in  scenarios  during  the  composition  and  validation  process.  This 
will  permit  the  test  officer  to  generate  test  case  data  for  testing  message- 
driven  systems. 

8.  DESCRIPTION  OF  INVESTIGATION. 

a.  Initially,  a  study  will  determine  the  degree  of  automation  for  which 
automated  test  data  generation  is  feasible,  and  the  cost  benefit  of  automating 
the  process.  The  development  of  requirements  for  instrumentation  is  not  a 
part  of  this  MIP.  Work  on  the  ongoing  TIS  will  be  examined  and  results  of 
this  investigation  integrated  into  the  TIS. 

b.  The  USAEPG  will  conduct  the  investigation  in  two  phases: 
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(1)  Information  on  message  types  and  contents  and  scenario  struc¬ 
tures  will  be  compiled  and  analyzed  to  determine  those  scenario  parameters  and 
constructs  that  are  used  frequently  and  which  are  amenable  to  automatic 
generation. 

(2)  For  several  specific  cases,  methods  of  automatically  generating 
the  scenario  contents  will  be  proposed,  computer  programs  designed, 
implemented,  and  tested,  and  scenarios  generated  and  validated.  The  method 
and  computer  program  will  be  documented  to  include  a  user's  guide  appropriate 
for  the  test  officer. 


Investigation  Schedule. 

MILESTONE/PHASE 

SCHEDULE 

FY  85  (Qtrs) 

1  2 

3  4 

Scenario  Analysis 

X  X 

X 

Propose  Methods 

X  X 

X 

Implement  and  Test 

X 

X  X 

Report 

X 

This  investigation  will 

result  in  a  new 

procedure  whereby  the  effec 

tiveness  of  scenario  generation  can  be  improved. 

e.  Environmental  Impact  Statement.  Execution  of  the  investigation  will 
not  have  an  impact  on  the  quality  of  the  environment. 

f.  Health  Hazard  Statement.  Execution  of  this  investigation  will  not 
involve  health  hazards  to  personnel. 

9.  JUSTIFICATION. 

a.  Association  with  Mission.  USAEPG's  primary  mission  is  to  conduct 
development  testing  of  C-E  equipment  and  systems.  In  support  of  this  mission, 
USAEPG  has  developed  extensive  experience  in  compatibility,  vulnerability,  and 
electronic  warfare  and  intelligence  testing  and  more  recently  has  pioneered 
efforts  in  automated  system  (software)  testing. 

b.  Capability,  Limitations,  Improvements,  and  Impact.  The  present 
scenario  composition  capability  is  manual  with  only  the  automated  prompting 
and  validation  of  operator  entries  for  the  composition  of  individual  messages. 
This  limits  the  timely  accomplishment,  the  coordination  of  test  messages,  and 
the  number  of  test  cases  that  can  be  composed  for  the  average  test.  Improve¬ 
ments  can  be  realized  by  automated  means  of  composing  scenarios.  The  impact 
of  failure  to  complete  this  investigation  will  be  a  reduced  ability  to 
generate  the  large  amount  of  data  required  to  test  C3I  systems. 

c.  Dollar  Savings.  In  addition  to  providing  a  capability  which  was 
previously  not  available  within  TECOM,  the  manhour  savings  as  gleaned  from  use 
of  the  initial  capability  on  MCS  is  estimated  to  be  a  factor  of  30.1. 

d.  Workload.  The  following  major  field  Army  automated  systems  are 
currently  under  development  and  are  programmed  for  testing  or  retesting: 


SYSTEM 


JTIOS 

MCS 

RPV 

PLRS 

SHORAD  C2 

JINTACCS 

PJH 

GPS 

ASAS 

FIREFINDER 
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e.  Association  with  Requirements  Documentation.  The  Army  Battlefield 
Automation  Interoperability  System  Engineering  Management  Plan  (BASEP), 
outlines  the  requirements  for  interoperability  testing.  This  project  will 
provide  the  capability  for  intra-  and  interoperability  testing. 

f.  Other.  None. 

10.  RESOURCES. 

a.  Financial. 


(1)  Funding  Breakdown. 

Dollars  (Thousands ) 

FY  85 

In-House  Out-of -House 

Personnel  Compensation 

Travel 

3.0 

Contract  Support 

110.0 

Consultants  A  Other  Svcs. 

10.0 

Materials  &  Supplies 

2.0 

Equipment 

ADP 

20.0 

Subtotal 

55.0 

T20 

FY  Total 

- i7snr 

(2)  Explanation  of  Cost  Categories.  (FY  85) 

(a)  Personnel  Compensation.  Direct  labor,  one  civilian 
part-time  chargeable  to  the  Investigation. 

(b)  Travel.  Three  to  five  trips  per  year  charged  to  Investi¬ 
gation. 

(c)  Contract  Support.  Required  to  complement  in-house  re¬ 
sources— Includes  consultants,  materials,  etc. 

b.  Anticipated  Delays.  None. 


c.  Obligation  Plan.  (Fiscal  Quarters  FY  85) 


Obligation  Rate 
(Thousands) 

d.  In-House  Personnel. 


Type 

Electronic  Engr  GS-855 


Number 

1 


GS-334 


FY  85 
Manhours 
Required 

“icir 

600 


Available 


Resolution  of  non-available  personnel.  NA. 


11.  INVESTIGATION  SCHEDULE. 


In-House 

Contract 


FY  85 

ONDJFMAMJJAS 


Symbols: 

—  Active  investigation 
...  Contract  monitoring 
R  Final  report  at  HQ,  TECOM 

12.  ASSOCIATION  WITH  TOP  PROGRAM 

a.  No  TOP'S  will  be  revised  as  presently  plarned. 

b.  Initial  plan  does  not  include  any  TOP,  but  the  investigation  will 
supply  the  desired  methods  from  which  procedures  can  be  formulated. 


FOR  THE  COMMANDER: 


MELVIN  FOWLER 
LTC,  SigC 

Director  of  Materiel  Test 
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APPENDIX  B 
ACRONYMS 


AMG . Automated  Message  Generation 

ASAS . All  Source  Analysis  System 

ASCII . American  Standard  Code  for  Information  Interchange 

C3I . Command,  Control,  Communications,  and  Intelligence 

C-E . Communications-Electronics 

DB . Oata  Base 

DBMS . Data  Base  Management  System 

DC3 1 . Distributed  C3I 

DOD . Department  of  Defense 

EFL . Event  Format  Library 

FY . Fiscal  Year 

GPS . Global  Positioning  System 

INGRES . Interactive  Graphics  and  Retrieval  System 

I/O . Input/Output 

ITIS . Interim  Test  Item  Stimulator 

JINTACCS . Joint  Interoperability  of  Tactical  Command  and  Control  Systems 

JTIDS . Joint  Tactical  Information  Distribution  System 

MCS . Maneuver  Control  System 

MFL . Message  Format  Library 

PJH . PLRS/JTIDS  Hybrid 

PLRS . Position  Location  Reporting  System 

RPV . Remotely  Piloted  Vehicle 

SHORAD  C2 . Short-Range  Air  Defense  Command  and  Control 

SMI . Soldier  Machine  Interface 

SUT . System  Under  Test 

TACFIRE . Tactical  Fire  Direction  System 

TECOM . U.S.  Army  Test  and  Evaluation  Command 

TIS . Test  Item  Stimulator 

TMDB . Test  Message  Data  Base 

TRANFILE . Data  Base  Transaction  File 

USAEPG . U.S.  Army  Electronic  Proving  Ground 

VISTA . Very  Intelligent  Surveillance  and  Target  Acquisition  System 
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APPENDIX  C 

TEST  ITEM  STIMULATOR 
OVERVIEW 


1.  TEST  ITEM  STIMULATOR  OVERVIEW 


The  TIS  supports  three  operational  functions  used  to  perform 
developmental  and  interoperability  testing  of  digital  message-driven  systems: 

•  Pre-test  scenario  preparation. 

a  Real-time  system  under  test  (SUT)  stimulation. 

•  Post-test  data  reduction  and  analysis. 

Figure  C-l  illustrates  the  data  flow  through  the  pre-test,  real-time,  and 
post-test  functions. 

1.1  Pre-Test 


The  pre-test  function  supports  on-line  generation,  review,  and  modifica¬ 
tion  of  test  scenarios.  The  pre-test  software  provides  the  interactive 
capability  to  maintain  a  data  base  of  messages,  called  the  Message  Format 
Library  (MFL).  Using  these  message  formats,  scenario  messages  can  be  created 
and  organized  into  groups,  called  events.  Events,  which  are  used  to  define 
scenarios,  are  maintained  in  the  Event  Format  Library  (EFL).  The  pre-test 
data  base  is  further  described  in  section  2  of  this  appendix. 

1.2  Real-Time 


The  real-time  function  provides  the  interface  for  stimulating  and  moni 
toring  the  SUT.  The  real-time  function  processes  scenario  and  operator- 
entered  messages,  producing  a  message  stream  to  stimulate  the  SUT.  The 
resulting  message  exchange  is  logged  for  later  processing. 

1.3  Post-Test 


The  post-test  processing  of  the  log  files  generated  during  testing 
produces  statistical  reports  on  message  content  and  end-to-end  system  through¬ 
put. 


2.  TEST  MESSAGE  DATA  BASE 


The  following  sections  describe  that  portion  of  the  TIS  test  message  data 
base  related  to  scenarios,  events,  and  message  formats.  Figure  C-2  depicts 
the  related  data  base  sub-schema. 

2.1  Scenarios 


a.  The  time-sequenced  scenario  files,  used  by  the  real-time  function, 
are  generated  from  data  base  scenarios,  created  and  maintained  through  the 
pre-test  function.  These  scenarios  are  represented  by  the  following  types  of 
records  (to  simplify  the  description,  some  fields  have  been  renamed  or  omit¬ 
ted): 


e  Scenario  description  (System  ID,  Scenario  ID,  Scenario 
Description,  Date  Created,  Date  Modified). 


l-gaMr-1  H 
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•  Scenario  notes  (System  10,  Scenario  ID,  Note  #,  Note  Text). 

•  Scenario  composition  (System  ID,  Scenario  ID,  Event  ID,  Event 
Start  Time). 

The  underlined  fields,  called  key  fields,  have  a  unique  combination  of 
values  for  each  record. 

b.  Each  scenario  is  described  by  one  Scenario  Description  record  and  a 
number  of  Scenario  Notes  records.  The  composition  of  each  scenario  is 
specified  by  a  number  of  Scenario  Composition  records--one  for  each  event 
used.  All  records  associated  with  a  specific  scenario  share  the  same  System 
ID  and  Scenario  ID.  Scenario  Notes  records  are  ordered  by  their  Note  # 
fields,  while  Scenario  Composition  records  are  differentiated  by  their  Event 
ID  and  Event  Start  Time  fields  (a  scenario  can  contain  several  instances  of  an 
event,  so  long  as  they  have  different  start  times). 

2.2  Events 


a.  Events  are  represented  by  the  following  types  of  records: 

•  Event  description  (System  ID,  Event  ID,  Event  Description). 

•  Event  composition  (System  ID,  Event  ID,  Message  Delta  Time, 
Segment  #,  Message  Type,  Message  Index,  Control  Fields). 

b.  Each  event  is  described  by  an  Event  Description  record,  which  is 
associated  by  the  System  ID  and  Event  ID  with  a  number  of  Event  Composition 
records.  Events  are  composed  of  messages,  which  are  made  up  of  one  or  more 
segments.  Each  message  of  an  event  is  described  by  one  or  more  Event  Composi¬ 
tion  records  as  follows: 

•  Single  segment  messages.  Single  segment  messages  are  represented 
by  a  single  Event  Composition  record— no  other  Event  Composition  records  share 
the  same  combination  of  System  ID,  Event  ID,  and  Message  Delta  Time  values. 

•  Multiple  segment  messages.  Multiple  segment  messages  are  defined 
using  two  or  more  Event  Composition  records  sharing  the  same  System  ID,  Event 
ID,  and  Message  Delta  Time  fields.  These  records  represent  individual  message 
segments  to  be  combined  during  real-time  scenario  file  generation  where 
concatenation  order  Is  based  on  the  Segment  #  values.  Unless  otherwise 
indicated,  message  segments  of  multiple  segment  messages  will  be  treated  as  if 
they  were  single  segment  messages. 

c.  The  Message  Delta  Time  fields  specify  each  message's  offset  from  the 
Event  Start  Time  of  that  particular  event.  The  message  type  field  specifies 
the  format  (field  structure)  of  each  message  or  segment.  The  various  control 
fields  contain  processing  data  used  during  scenario  file  generation  and 
real-time  processing. 

d.  The  System  ID,  Event  ID,  Message  Delta  Time,  and  Segment  f  fields  are 
collectively  referred  to  as  the  message  key  fields. 

e.  The  message  index  field  Is  used  to  access  the  actual  message  data 
fields  which  are  stored  In  the  following  type  of  record: 
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Field  Data  (Message  Index,  Field  #,  Data) 


The  data  fields  associated  with  a  particular  message  are  stored  in  Field 
Data  records  that  have  the  same  message  index  value  as  the  Message  Index  field 
in  that  message's  Event  Composition  record. 

2.3  Message  Formats 

a.  The  following  types  of  data  base  records  are  used  to  define  message 
formats: 


•  Message  Description  (System  ID,  Message  Type,  Description). 

•  Message  Composition  (System  ID,  Message  Type,  Field  #,  Field  Type, 
Field  Location). 

•  Field  Conversion  (System  ID,  Field  Type,  Conversion  Data). 

•  Conversion  Table  (System  ID,  Field  Type,  ASCII  Value,  Bit  Value). 

b.  Message  formats  are  described  with  a  Message  Description  record. 
Each  field  of  a  particular  type  of  message  is  defined  using  Message 
Composition  records  that  share  the  same  System  ID  and  Message  Type.  The  Field 
Type  value  indicates  the  field's  type,  which  is  detailed  by  a  Field  Conversion 
record.  The  Field  Conversion  information  is  used  with  the  Conversion  Table 
information  during  the  scenario  generation  process,  where  the 
character-oriented  data  base  scenario  is  converted  into  the  real-time  scenario 
file. 
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